FIG. 1 of the accompanying drawings is a simplified illustration of the 3GPP network architecture. The Figure is derived from 3GPP TS 23.401 V9.1.0 (2009-06), General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 9). Unless otherwise stated, further references herein to “the standard” relate to TS 23.401, and unless otherwise stated any references herein to TS 23.401 relate to the above version of the standard.
In 3GPP networks, user packets travel through a significant portion of the access network encapsulated in a GTP-U tunnel. The GPRS Tunnelling Protocol (GTP) header of the incoming packet, especially one of its field, the Tunnel Endpoint Identifier (TEID) is used in combination with the tunnel endpoint's IP address to explicitly identify the bearer of the User Equipment (UE).
In SAE/LTE, the Serving Gateway (SGW) and the base station uses the TEID in the received packet's GTP header to forward the packet to the appropriate bearer. Based on the incoming TEID, the SGW selects a GTP or Proxy Mobile IP (PMIP) based tunnel leading to the Packet Data Network (PDN) Gateway (PGW). Based on the incoming TEID, the Evolved NodeB (eNodeB) selects the appropriate radio bearer (leading to a specific UE). There are two alternative tunneling possibilities between the SGW and PGW, one is GTP tunneling similarly as between the Radio Base Station (RBS) and SGW and the other is using PMIP with Generic Routing Encapsulation (GRE) tunneling. (The latter is also based on per-UE tunnels, where the identifiers are different but the concept proposed here works similarly also in this case, so in the following we do not deal with PMIP tunnels).
In 3G networks, GTP is used between the Serving GPRS Support Node (SGSN) and the Radio Network Controller (RNC) as well as the SGSN and Gateway GPRS Support Node (GGSN). Based on the incoming TEID, the SGSN selects a GTP tunnel leading to the GGSN. Based on the incoming TEID, the RNC selects the appropriate radio bearer (leading to a specific UE through the appropriate NodeB). In converged 3GPP networks the traffic from 2G/3G access and SGW is also transported in GTP tunnels.
Lately, with the introduction of broadband mobile technologies and change of subscriber behaviour (shifting towards more high volume media download), coping with the increased traffic volume in the mobile radio access (RAN) has become a stringent problem. One possibility to off-load the access is to apply caches (or other local streaming servers) that would serve some parts of the requested content (media, web, etc). In this way, it is possible to achieve transport gain above the cache. Additional benefits of RAN caching is the possibility for QoS/QoE enhancement by reducing the transport delays and also reduced peering cost.
The reader is also referred to 3GPP TS 22.101 10.1.0 (2009-12), Service aspects; Service principles (Release 10), Section 4.3.5.
The present applicant has identified the following issues.
Below the cache there is no transport gain. Besides, transport cost is highest and transport bottleneck problems arise at low-RAN. Thus, the applicant has appreciated that it would be most advisable to move the caches and streaming servers as close to the RBSes as possible.
A standard architecture has not been developed for caching in the 3GPP RAN close to the RBS. One relevant activity is the offload architectures for selected traffic (e.g. Internet) towards a defined IP network close to the UE's point of attachment to the access network (see TS 23.401). The motivation for this requirement (together with the similar requirement for local IP access (LIPA) for the home (e)NodeB subsystem) is to decrease operator expenses, because in many cases it would be suboptimal to carry the traffic all way up to a central PGW, especially if that traffic may be offloaded locally at lower price to a local service network or to the Internet.
The technical solutions for achieving the selected IP traffic offload (SIPTO) have not been fully worked out yet, but technical alternatives are under discussion as set out in 3GPP TR 23.829 V0.4.0 (2010-01), Local IP Access and Selected IP Traffic Offload (Release 10). It has been decided that for Release 10 two main alternatives will be supported by the standard:                One based on selection of a closer PDN GW for specific types of traffic and        Another based on traffic breakout from the GTP tunnels.        
The advantage of the first alternative is that traffic break-out (including break-out for caching purposes) may be achieved by architectural solutions that do not require significant changes to the current 3GPP architecture (the Gateway (GW) address for the closer GW is either suggested by the RAN node or is selected by enhanced DNS-based mechanisms). However, it is not obvious that designing small nodes with PDN GW functionality is economically feasible. Also, it may be a problem to provide secure network environment for these distributed GWs, whose functions (legal intercept, charging, policy enforcement) require such an environment.
Solutions for the latter method generally involve some kind of Network Address Translation (NAT) to be able to offload traffic from a tunnel below the IP point of presence.
Any type of caching solution involving traffic break-out from the GTP tunnels has to deal with the issue of getting the proper tunnel information for a given traffic flow. On one hand this includes receiving the information about new tunnels during attach, but also updating the tunnel information when this changes, e.g. during handovers, when the tunnel endpoints change. One straightforward solution for this problem is to interface to certain core network nodes (Mobility Management Entity—MME, SGW) to get the required information.
However, in practice the mobile operators purchase the core and RAN nodes through different tenders, thus it may happen that one vendor ships the RAN solutions while another vendor ships the Core Network (CN) solution. In such cases, proprietary interface to a CN node is not an option, so other methods are needed to handle tunnel information update that involves intercepting mobility signalling messages, or interfacing to RAN nodes.
A known caching solution (see US 2010/0034089) is based on a cache acting as a proxy both in the user and control plane, i.e., the cache emulates the respective protocols on either side of the interception point. The patent describes in details how the cache monitors the RANAP protocols to get user and bearer information for the case of a cache inserted between the RNC and SGSN in a 3G network. Mobility handling is also described for this case, based on intercepting the relocation request from the RNCs. However, this solution cannot be generalized for the LTE access unless some communication with some core network nodes (SGW or MME) is assumed.
Another issue when interfacing to RAN nodes only is to ensure that the cache is always ‘on-path’, i.e. the data traffic with subscriber requests reaches the cache. One solution to this that does not require any new function from the cache or mobile network side is to guarantee with proper transport network configuration that traffic from a set of downlink tunnel endpoints and a set of uplink tunnel endpoints goes through the same cache entity. In this respect, the phrase “downlink tunnel endpoint” is used herein to denote the endpoint (or head end) of a tunnel in a downlink direction towards the mobile node; for example the downlink tunnel may be from a core network node such as a SGW to a RBS, with the RBS in this case being the “downlink tunnel endpoint”. Similarly, the phrase “uplink tunnel endpoint” is used herein to denote the endpoint (or head end) of a tunnel in an uplink direction away from the mobile node; for example the uplink tunnel may be from the RBS to a core network node such as a SGW, with core network node such as the SGW in this case being the “uplink tunnel endpoint”.
A few alternative solutions to this issue exist:                Routing configuration, i.e. use IGP or BGP routing settings that guarantee that the traffic to and from a set of RBSes will pass a certain traffic redirect/cache entity. One example is shown in FIG. 2 of the accompanying drawings, where it is assumed that each cache is configured as a single OSPF area border router for a group of RBSes.        Policy-based routing, i.e. use special routing configuration in the network routers that ensures that traffic from and to a set of downlink tunnel endpoints will be routed through a selected cache entity.        Virtual Private Network (VPN)-based connectivity, i.e. use using some VPN-type of solutions between the cache and the upper tunnel endpoints, see FIG. 3 of the accompanying drawings, that makes it possible that the downlink tunnel endpoint addresses are advertised through the cache. This assumes that some tunnel between a group of downlink tunnel endpoints and the cache is pre-configured.        
A common problem of these solutions is that it may be very cumbersome to reconfigure the current transport and routing infrastructure in a real network environment to get the proper transport configuration. Also, basic operation and maintenance use cases (adding or removing nodes) may imply a full transport network reconfiguration.
Another problem arising is that since none of the RAN nodes is a mobility anchor, it may happen during mobility that the data path of a given terminal changes in a way that it will no longer reach neither the cache nor the RAN nodes the cache is interfacing with. This will require a database to store information about where to forward the packets of ongoing flows. The configuration of connectivity to such a database from any cache in the system may be cumbersome, too.
It is desirable to address the issues described above.